Introduction
The project was performed as a group of 3, consisting of myself, Kelvin Fernando Cardona Fonseca, and Ifeoluwa Ojo, and the goal of the project was to develop and application to be used by a racecar driver that provides information on the cars velocity, the engines temperature, and the pressure of the tires. The app would be deployed to a hololens headset, and would be developed in Unity. The project utilized the Scrum framework to plan out the project and to keep track of who is responsible for each part.
The project used an IoT kit to gather telemetry data. This data is then sent to Azure IoT Central, and then to Azure Event Hubs. The data is then sent into
Azure blob storage though stream analytics where a query trims down the telemetry data to only include the value needed for the thermometer, pressure gauge, and the speedometer.
The Blob Storage then generates a SAS token that will be called by UnityWebRequest to get the telemetry data into unity. Unity is then used to develop the UI elements of the app,
which are then deployed to the Hololens.
Azure blob storage though stream analytics where a query trims down the telemetry data to only include the value needed for the thermometer, pressure gauge, and the speedometer.
The Blob Storage then generates a SAS token that will be called by UnityWebRequest to get the telemetry data into unity. Unity is then used to develop the UI elements of the app,
which are then deployed to the Hololens.
The project was divided into 5 scrum sprints and a finalizing period.
Sprint 1
I was responsible for the DevKit, and during the first sprint the main objective was planned
to be getting the DevKit up and running. However, since this sprint fell into the middle of the exam period, the goals from sprint 1 were not completed during this initial sprint.
to be getting the DevKit up and running. However, since this sprint fell into the middle of the exam period, the goals from sprint 1 were not completed during this initial sprint.
Even though the DevKit was not completely setup, some time was spent to familiarize myself with the Devkit, downloading all the prerequisites as well as setting up the azure account needed. There were some problems regarding the setting up of the Azure account part. Azure did not recognize Uppsala university as an eligible university when trying to set up a student account. So instead, I had to create a personal account.
Reflection: Since this sprint fell during exam period, it was an intentional decision to postpone most of the project during this sprint, and as such there was not much to reflect on.
Sprint 2
During this sprint, I finished setting up the DevKit and getting access to the telemetry data.
The main issue here was that the guide we had been provided stated that when setting up the DevKit the template should be set to none. This caused the DevKit to not be able to connect to Azure IoT central. However, after getting some help, I was able to set up the template, and everything else worked without any problems.
We also decided on our application, in which I was the leading force in the brainstorming. We decided on a interface for a racecar that visualizes data such as the temperature of the engine, the pressure in the tires, a compass(which would later be removed), and a speedometer. By the end of this sprint the group did a round of peer evaluations.
The main issue here was that the guide we had been provided stated that when setting up the DevKit the template should be set to none. This caused the DevKit to not be able to connect to Azure IoT central. However, after getting some help, I was able to set up the template, and everything else worked without any problems.
We also decided on our application, in which I was the leading force in the brainstorming. We decided on a interface for a racecar that visualizes data such as the temperature of the engine, the pressure in the tires, a compass(which would later be removed), and a speedometer. By the end of this sprint the group did a round of peer evaluations.
Reflection: With sprint one being postponed, this was the time to get back on track. All the goals of first two sprints were successfully completed. Overall this was a very productive sprint on my part.
Comments from peers:
Kelvin:
"Ludvig has taken the initiative in every task performed by the team. He participated actively in every discussion, and helped the team solved various problem, leading many of the tasks done. He coordinated very well with Ife on setting the input section of the pipeline and getting the data to IoT Hub."
"Ludvig is a great group member. He takes a great deal of responsibility and ownership of the tasks to be performed. He takes the initiative in working and discussing and has demonstrated the ability to coordinate to complete tasks."
"Ludvig successfully set up the Devkit and created an Azure account. He connected the telemetry data into IoT central which was a key achievement in our project's development. Ludvig actively contributed to discussions about the application's scope and selecting appropriate sensors, aligning our efforts with project objectives. Overall, his collaborative spirit helped in the success of Sprint 1-2 tasks."
Sprint 3
During this sprint my main contribution was helping with modifying the query and creating the SAS and JSON file. I was also starting to look in to learning unity during this sprint.
Reflection: All in all, this sprint was a far worse personal performance than the last was. Not enough time was spent on the project, and the query did not end up in a state that would be usable and was instead left to be worked on during later sprints.
Sprint 4
This entire sprint I spent on diving into and learning unity. A teammate had been responsible for getting started with unity during earlier sprints, so this was the time I got brought up to speed on what was going on.
Reflection: There was definitely an improvement in the amount of work put into the project during this sprint.
However, there was definitely room for even more improvement, since the amount of work put in was not enough to get us back on track, but simply kept us from falling further behind.
However, there was definitely room for even more improvement, since the amount of work put in was not enough to get us back on track, but simply kept us from falling further behind.
Sprint 5
I developed the first UI element, the speedometer, during this sprint. The speedometer also served as a base upon which the temperature gauge would built. During this sprint I also worked on deploying the app to the hololens.
However, the query and SAS token had not yet been finalized, meaning that they were still using placeholders for the data.
However, the query and SAS token had not yet been finalized, meaning that they were still using placeholders for the data.
Reflection: At this point the project should have been close to completed, however we still had yet to finalize the query and the SAS tokens. Which also meant that everything build in unity still needed to be modified when these were finished. These things should have been done by now, and leaving them to the finalizing period was not a good idea.
Finalizing period: I created a data table within unity too store the telemetry data, as well as created the script to fill the table with data from the now 4 different JSON files gotten by using the corresponding SAS tokens. I also updated all the UI elements so that they pulled and used data from the data table. Unfortunately my personal azure account expired during this period, meaning that the Devkit needed to be setup again with another account. Finally I took part in the deployment of the app to the hololens headset. There was also a second peer review done at this point.
Reflections: This was probably my most productive section of the project, spending a lot of time in unity to get everything working with the finalized SAS token, as well as having to redo most of the work done during sprint 1 and 2.
Looking back on the project as a whole, I am very happy with my contributions. However in hindsight I needed to take even more initiative to ensure we were not falling behind. Even though I liked working with the group, none if my team members were are natural leaders that take charge and pushes the project forward. So that burden would fall on me, and I should have realized this and been actively thinking about planning the next work session.
Kelvin:
"Ludvig, again demonstrated a lot of initiative and coordination when working with Ife for the creation of the SAS token. He also learned very fast how to work with Unity and the job done on it so far. He was very active in the design and coding, taking ownership of some features of the application. He was also very active in problem solving and task performance, for example, with the deployment and reading JSON files with UnityWebRequest. He was very willing to work a lot when required, even when things were needed to be re-done, like the DevKit set up."
"Again, Ludvig, has demonstrated to be a great team member. He is a very fast learner and is always willing to take the initiative. He also has helped the team a lot when getting stuck or when problems arise."
"Ludvig has made good contributions during the project, demonstrating versatility by participating in tasks such as learning Unity, and developing key features like the speedometer and data table. His involvement in deploying the app and updating UI elements with real data. However, Ludvig's sudden week-long silence without communication had a notable impact on the team's progress. Recognizing that everyone's contribution is essential at all times, addressing and improving communication will enhance the overall efficiency and success of the team."
Benefits and limitations
The idea of using AR headset like the hololens to display information about the car to a driver is cool in theory, but after working on it, I'm actually not that sold on the concept. In this project we used a IoT kit to gather the data to then be sent to the hololens. However in an actual application, the data needs to come from sensors connected to the car. And at that point, it seems way simpler and more practical to simply have all the data displayed on the car dashboard, especially considering the cost and limitations of an AR headset.
However, if the information the headset provides was information that is not directly received from the car, the idea sounds a lot more usable. For example implementing data regarding weather forecast, a GPS that can indicate to you what lane you should be in, or displaying the current speed limit.
Ethical implications of driving with a headset
One of the implications you need to take in consideration when developing an app for an AR headset, is whether or not it is appropriate to have a camera in the environment that the app is designed to be used in. In our case here that is of very little concern. Most roads are public meaning there should be no expectation of privacy on them, and dash cams are already a thing that are seeing widespread use.
What does need to be taken into consideration though is the act of driving with a headset. Limiting a drivers field of vision is a dangerous area to play in, meaning any UI elements needs to be sufficiently non intrusive. There is also the fact that it is prone to misuse. Giving a driver an excuse to use a technology that can easily be used for other activities might cause people to drive with the headset, and then start using it for entertainment while they are driving, similar to how people already are using their phone when driving.
